Thin clients are generally defined as clients that perform little or no local data processing. Such thin clients may rely on central computer such as a server to execute applications. The clients and the server are coupled to one another via a network. The server generally provides audio and video data over the network to the thin client (e.g., a desktop device). The desktop device may play back the audio data or display the video data as such data is received from the server.
In, for example, a Sun Ray® thin client product, video rendering may be done largely through the use of server graphics virtualization in which the server continuously pushes its screen activity to the client. Actual “screen scraping” of the display contents may be performed as a last resort. This model provided for effective performance early on, however the style of graphics programming has evolved over time which makes screen scraping less effective.
More applications now compose the contents of their windows internally, and simply transfer those contents into the frame buffer. For example, such applications may include various web browsers. For example, consider what happens when a user uses the scroll button to move a page on a display up or down. Early coding practice may have included simply copying the part of the page that remains on the screen to its new position, and then filling in new contents of the page that were exposed. This implementation may have been performed efficiently without consuming a large amount of bandwidth to send to updates to the client. However, in current programming practice it is likely that the entire contents of the region where the page is displayed will be updated by being overwritten. In general, since the contents have moved, substantially every pixel in the window changes and must be transmitted from the server to the client.
This condition generally means that it is may be worthwhile to attempt to detect when the update to the screen (i.e., on the client) is actually the result of a scroll operation (i.e., a significant portion of the screen is the same as the previous contents, but moved to a new location). It may be difficult from an efficiency perspective in moving a substantial number of pixels to the client when the contents of the screen have moved because the scroll offset may be one of a larger number of values. This brute force method is generally not satisfactory for determining the scroll offset if it is one of a larger number of values.